Blazor WASM vs Blazor Server

Some brief notes on Blazor WASM vs Blazor Server.

Blazor WASM

Pros

• Faster UI code
• Offline support
• Server not required - but will need a server to run API if required

Cons

• Need to build an API layer to access secure resources which introduces complexity
• Code is sent to browser. But this is similar to sending JaavScript code files to the browser.
• Visual Studio debugging, at the time of writing, has some limitations:
  • It can’t break on unhandled exceptions
  • It can’t hit breakpoint during app startup

Blazor Server

Pros

• Quicker to load - smaller download (only JS, HTML, CSS etc)
• Easier to access secure resources that require credentials
• Supports older browsers that don’t support WASM (e.g. IE 11)

Cons

• Extra latency - every UI interaction requires a round trip to the server
• No offline aupport
• Server required to serve the application
• Server scaling needs to be considered - see below

Blazor Server Scaling

Every user in a Blazor Server application requires some server resources. Below is a guideline of what is required.

• 85K of server memory overhead for every client connection - this doesn’t take into account data within the page. So avoid having large datasets on a page.

  • Blazor Server app uses Websockets as part of the SignalR connection.
    • This can be removed from the application by using Azure SignalR Service. This can scale up to 100K concurrent users
      • Free version of Azure SingalR Service that support 20 users, 20k message per day
      • Or a Standard version of Azure SingalR Service that supports 1000 users and 1 million messages per day per unit. 1 unit is £1.20 per day and you can have up to 100 units.

• Micosoft real world test for using Blazor Server

  • 1 CPU + 3.5GB RAM - 5k concurrent connections (Similar to S2 or P1v2 Azure App service)
  • 4 CPU + 14GB RAM - 20k concurrent connections (Similar to P3v2 Azure App service)

Note: If using more than one server you will need to persist state outside of server.